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ABSTRACT 

In  this  paper  we  present  a  means  of  compensating 
for  the  semantic  deficits  of  linguistically  naive 
underlying  application  programs  without  com¬ 
promising  principled  grammatical  treatments  in 
natural  language  generation.  We  present  a  method 
for  building  an  interface  from  today's  underlying 
application  programs  to  the  linguistic  realization 
component  Mumble-86.  The  goal  of  the  paper  is  not 
to  discuss  how  Mumble  works,  but  to  describe  how 
one  exploits  its  capabilities.  We  provide  examples 
from  current  generation  projects  using  Mumble  as 
their  linguistic  component. 

INTRODUCTION 

Work  in  artificial  intelligence  has  two  goals:  on 
the  one  hand  to  do  concrete  work  that  can  be  used  in 
actual  systems  today,  on  the  other  to  establish  strong 
theoretical  foundations  that  will  allow  us  to  build 
more  sophisticated  systems  tomorrow. 
Unfortunately,  since  the  field  is  so  young  and  so  few 
problems  are  well  understood,  these  two  goals  are 
often  at  odds. 

Natural  language  generation  is  no  exception.  The 
years  of  research  in  linguistics  have  made  problems 
in  syntax  comparatively  well  understood. 
Nevertheless,  we  should  not  restrict  ourselves  to  just 
generating  single,  isolated  sentences  until  the 
problems  of  lexical  semantics,  discourse  structure, 
and  conceptual  modeling  are  understood  as  well.  We 
must  find  ways  to  facilitate  both  efforts, 
modularizing  our  systems  so  that  the  parts  that  handle 
well  understood  processes  need  not  be  compromised 
to  accomodate  weaknesses  in  other  parts  of  the 
system.  This  paper  is  on  how  to  support  such 
modularity  in  a  natural  language  generator. 
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In  the  present  case,  the  well  understood  process  is 
linguistic  realization,  and  the  weaknesses  are  in  the 
conceptual  models  and  representations  of  the 
programs  underlying  the  generator.  To  bridge  this 
gap,  we  present  a  specification  language,  to  be 
used  as  input  to  the  linguistic  realization  component 
Mumble-86.2  This  language  provides  the  designer  of 
a  planning  component  with  a  vocabulary  of  linguistic 
resources  (i.e.  words,  phrases,  syntactic 
constructions)  and  a  straightforward  means  of 
directing  their  composition.  The  specification 
language  facilitates  interfacing  Mumble  to  a  wide 
range  of  underlying  programs  and  planners.  For 
simple  programs  not  built  with  language  in  mind,  we 
show  a  straightforward  means  of  using  predefined 
templates  to  map  underlying  objects  to  complex 
linguistic  structures.  For  systems  with  more 
sophistication  in  text  planning,  we  show  how  the 
compositionality  and  flexibility  of  the  specification 
language  can  be  used  to  make  their  task  easier.  What 
is  template  driven  at  one  end  of  the  range  can  be  built 
compositionally  at  the  other;  what  is  stipulated  at  one 
end  can  be  reasoned  about  at  the  other. 


A  MOTIVATING  EXAMPLE 

Consider  the  description  "53rd  Mechanized 
Division" .  In  most  programs  today  a  sufficient 
representation  of  the  object  it  names  could  be  just  the 
symbol  53RD-MECHANIZED-DIVISION.  The  print 
name  of  the  symbol  conveys  all  the  information  that  a 
person  reading  the  code  needs  to  know,  without  it 
actually  playing  a  role  in  the  program's  reasoning.  If 
all  we  cared  about  were  a  single  communicative 
context,  we  might  consider  implementing  the  link 
between  the  symbol  and  the  description  as  though  the 
phrase  were  one  long  word  without  any  internal 
structure.  This  expedient  treatment  would  severely 

2  For  a  comprehensive  description  of  Mumble-86,  see  Meteer, 
McDonald,  Anderson,  Forster,  Gay,  Huetmer,  &  Sibun  1987. 
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limit  our  options,  however.  Indefinite  references, 
such  as  "a  mechanized  division",  and  subsequent 
references,  "the  division",  would  have  to  be  handled 
separately.  Pronominalization  would  not  be  possible 
since  there  are  no  associated  features  such  as  number, 
gender,  and  person.  Furthermore,  since  an  artificial 
word  would  have  no  internal  syntactic  structure,  a 
speech  production  program  would  have  no 
information  on  which  to  base  intonation.  A  better 
treatment  is  to  introduce  into  the  interface  itself  some 
of  the  generality  and  structure  that  the  underlying 
representation  is  missing. 

In  the  ALBM  interface  being  developed  at  BBN, 
we  associate  an  object  like  53RD-MECHANIZED- 
DIVISION  with  the  application  of  a  general  template  to 
an  explicit  set  of  arguments  as  shown  below: 


(def ine-default-3peoification 

' 53rd-mechanized-divi3ion 
! template-name  armed-foroea-unit-name 
;argument3  ("53rd"  "Mechanized"  "Diviaion")  ) 

HGURE 1 


By  going  to  this  slightly  greater  effort,  we  have 
supplied  a  hook  for  handling  subsequent  reference  or 
other  abstractions  ("the  53rd  and  42nd  mechanized 
divisions")  without  first  requiring  that  the  underlying 
program  contain  the  necessary  semantic  distinctions 
and  linguistic  information.  We  return  to  this 
example  later  and  show  how  the  template  named  in 
Figure  1  builds  an  input  specification  for  Mumble. 


MUMBLE'S  PLACE 
IN  THE  GENERATION  PROCESS. 

A  key  question  is  what  information  the  input 
specifications  to  Mumble  represent.  This  amounts  to 
asking  how  we  take  the  generation  process  to  divide 
into  subprocesses — what  decisions  have  already  been 
made  and  are  reflected  in  the  specifications,  and 
which  ones  remain.  Since  we  have  positioned  the 
level  of  the  specification  language  so  as  to  fit  the 
decomposition  reflected  in  our  own  work  and  to 
expedite  the  use  of  Mumble-86  by  other  researchers, 
the  answer  can  be  given  quite  precisely.  For  a  more 
complete  discussion  of  our  approach  and  how  it 
contrasts  with  other  work,  see  (McDonald,  Meteer,  & 
Pustejovsky,  1987).  Overall  we  can  divide  the 
generation  process  into  three  coarse  stages: 


Underlying  program  —  Developed  inde¬ 
pendently  of  the  generator  per  se,  this  will  be  the 
expert  diagnostician,  cooperative  database,  ICAI 
tutor,  etc.  that  the  human  users  want  to  talk  with. 
Some  event  within  this  underlying  program  will 
determine  the  goals  the  utterances  are  to  achieve  and 
initiate  the  generation  process. 

Planning  —  This  process  determines  how  the 
goals  can  be  achieved  in  a  given  context.  This 
includes  selecting  the  information  to  be 
communicated  (or  omitted),  determining  what 
perspectives  and  rhetorical  organization  the 
information  should  be  given,  and  choosing  a  mapping 
for  the  information  onto  the  linguistic  resources  that 
the  language  provides  (i.e.  open-class  words  and 
syntactic  constructions). 

Realization  --  This  process  carries  out  the 
planner’s  specifications  to  produce  an  actual  text.  It 
has  the  responsibility  for  insuring  that  the  text  is 
grammatical,  and  will  handle  the  bulk  if  not  all  of  the 
syntactic  and  morphological  decision  making. 

In  these  terms,  Mumble-86  is  a  realization 
component.^  As  such,  we  expect  any  system  that  uses 
it  to  be  able  to  supply  the  following  kinds  of 
information  about  each  utterance  that  it  wants 
produced,  couching  the  information  in  terms  of  our 
specification  language.  Mumble-86  is  agnostic  as  to 
whether  this  information  was  assembled  by  a 
theoretically  interesting  planning  component  or 
merely  stipulated  in  predefined  templates. 

(a)  The  units  from  which  the  utterance  is  to  be 
composed.  The  mapping  for  each  unit  to  its  intended 
linguistic  resource  will  either  have  been  already 
made  or  will  be  fully  defined  for  later  execution. 

(b)  The  functional  relationships  among  the  units, 
e.g.  predication,  head,  modifier,  given,  theme,  etc., 
that  direct  or  constrain  the  units'  organization  within 
the  text. 

(c)  Lexical  choice.  As  the  primary  means  of 
delimiting  what  information  is  or  is  not 
communicated  and  what  perspectives  and 
connotations  are  presented,  all  open  class  words  are 
choosen  by  the  planner. 


3  We  also  refer  to  Mumble  as  a  "linguistic  component", 
reflecting  the  fact  that  all  of  the  planners  and  underlying 
programs  that  have  been  used  widi  Mumble  to  date  have 
concentrated  on  conceptual  issues  and  left  all  of  the  linguistic 
efforts  to  it;  this  designation  may  have  to  change  in  the  coming 
years  as  the  semantic  and  discourse  level  contributions  of  earlier 
components  become  more  significant. 
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We  see  our  specification  language  as  providing  a 
medium  for  the  results  of  a  planner’s  decisions.  The 
syntax  of  the  language  provides  a  flexible, 
compositional  notation  by  which  a  planner  may  view 
the  potential  linguistic  form  of  the  utterance  it  is 
constructing  without  having  to  understand  the  myriad 
details  entailed  by  descriptions  at  the  level  of  the 
surface  structure.  In  the  next  section,  we  describe  the 
syntax  of  the  specification  language.  We  then  look  at 
how  predefined  templates  can  be  used  to  abstract 
away  some  of  the  details  to  make  it  easier  for  a 
planner  to  construct  them. 


THE  INPUT  SPECIFICATION  LANGUAGE 

Mumble's  input  specifications  may  be  seen  as 
expressions  over  a  vocabulary  of  elementary  terms 
and  a  syntax  for  their  composition.  In  defining  this 
language,  our  choice  of  terms  and  compositional 
operators  was  driven  by  what  appears  to  be  most 
useful  at  the  linguistic  level.  The  simplest 
expressions  in  the  language,  kernel  specifications, 
represent  the  choice  of  a  class  of  phrases  with  a 
lexical  head  and  the  specification  of  its  arguments. 
This  reflects  our  belief  that  one  almost  never  chooses 
just  to  use  a  certain  word,  but  rather  to  describe  an 
action  with  a  verb  and  a  specific  set  arguments  for 
example  (see  also  Kegl,  1987).  The  result  of 
realizing  a  kernel  is  a  phrasal  unit  comparable  to  an 
elementary  tree  of  a  Tree  Adjoining  Grammar.  (See 
Joshi,  1987,  for  a  discussion  of  properties  of  a  TAG 
which  make  them  well  suited  to  generation.) 
Formally,  a  kernel  consists  of  a  realization  function 
and  a  list  of  arguments  which  are  applied  to  it,  where 
a  realization  function  is  typically  a  class  of  phrases 
distinguished  by  the  characteristics  of  the  syntactic 
contexts  in  which  they  may  appear.  Executing  the 
realization  function  consists  of  choosing  among  the 
phrases  and  instantiating  the  choice. 

Larger,  more  complex  utterances  are  formed  by 
composing  kernels:  joining  them  syntactically 
according  to  the  relationships  between  them.  This 
process  is  analogous  to  adjunction  in  a  TAG.  In 
Mumble,  these  compositional  expressions  are  called 
bundles.  They  have  three  major  parts: 

(1)  The  head  is  either  a  kernel  or  a  bundle;  it  is 
realized  first,  as  an  "initial  tree"  into  which  other 
specifications  are  attached;  every  bundle  must  have  a 
head. 


(2)  Further-specifications  have  two  parts,  a 
specification  (either  a  kernel  or  a  bundle)  and  an 
attachment  function,  which  constrains  where  the  new 
tree  may  be  adjoined  to  the  surface  structure  already 
built;  diese  correspond  to  the  "auxiliary  trees"  of  a 
TAG;  a  bundle  may  have  any  number  of  further 
specifications. 

(3)  Accessories  contain  information  about 
language-specific  syntactic  details,  such  as  tense  and 
number.  Each  bundle  type  has  a  specific  set  of 
obligatory  and  optional  accessories  associated  with  it. 

Note  that  bundles  are  not  constrained  as  to  the  size  of 
the  text  they  produce:  they  may  produce  a  single 
noun  phrase  or  an  entire  paragraph. 

Figure  2  shows  a  representation  of  the  input 
^ecification  for  the  description  '’53rd  Mechanized 
Division"  discussed  at  the  beginning  of  the  paper.  In 
the  next  section  we  describe  how  this  specification 
could  be  built  from  an  object  in  the  underlying 
program. 


#<bundle  general-np 

:head  #<kernel  : realization-function 
np-corration-noun 
: arguments  ("division")  > 

: further-specifications 
( ( :  specification 

♦<lcernel  :  realization-function  adjective 
larguments  ("53rd") > 

: attachment-function  restrictive-modifier) 

( : specification 

#<lcernel :  realization-function  adjective 
:argument3  ("mechanized") > 

: attachment-function  restrictive-modifier) ) 

: accessories  (:number  singular 
: gender  neuter 
:per3on  third 

: determiner-policy  no-determiner) > 


nCURE  2 


Specifications  are  implemented  as  structured 
objects,  indicated  by  the  "#<  ...  >"  convention  of 
CommonLisp;  the  first  symbol  after  the  "<"  gives  the 
object's  type.  Other  symbols  are  either  object  names 
(e.g.  "general-np"),  or  in  a  few  cases  print  forms  of 
whole  objects  (such  as  the  accessories  and  their 
values).  Strings  in  double  quotes  (e.g.  "53rd'') 
designate  words. 
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DIRECT  MAPPING:  THE  SIMPLE  CASE 

The  granularity  and  vocabulary  of  the  input 
specification  language  are  designed  to  be  well  suited 
for  generating  natural  language.  In  principle  the 
semantic  organization  could  match  the  structure  of 
the  specification  language  exactly.  If  this  were  the 
case,  the  mapping  between  units  in  the  underlying 
application  program  and  the  specifications  to  the 
generator  would  be  direct  and  one  to  one.  However, 
we  cannot  assume  that  today's  underlying  program 
will  have  the  same  granularity  or  be  able  to  reason  in 
the  same  vocabulary.  For  example,  while  the 
accessories  NUMBER,  GENDER,  and  PERSON  in  the 
specification  above  are  necessary  to  determine  the 
correct  pronoun,  few  underlying  programs  working 
with  mechanized  divisions  would  bother  to  represent 
their  gender.  Rather  than  force  a  planner  to  deal  in 
these  terms,  we  provide  a  framework  for  building 
specifications  piecemeal  by  applying  templates  that 
can  be  specialized  to  the  application.  Templates  are 
abstractions  of  specifications,  which  stipulate  some  of 
the  terms  in  the  specification  and  parameterize 
others.  An  object  in  the  underlying  program  may  be 
mapped  to  a  template  through  a  default  specification, 
as  illustrated  in  Figure  1  and  repeated  below  along 
with  the  template  ARMED  -FORCES-UNIT-NAME: 

(define-default-specification 

' SStd-mechanized-diviaion 
: template-name  armed-foroes-unit-name 
:arguments  ("53rd"  "Mechanized"  "Division")  ) 

(define-specificat ion-template 

armed-forces-unit-name 
(number  type  size) 

(let  ( (K  (make-a-lcernel  ' np-comraon-noun  size)) 

(B  (ma)ce-a-bundle  'general-np) ) ) 

(set -bundle-head  B  K) 

(neuter-S-third-person  B) 

(singular  B) 

(no-determiner  B) 

(add-specializing-description 

(property- realized-as-an-adjective  number) 

B) 

(add-specializing-description 

(property- realized-as-an-adjective  type) 

B) 

B)  ) 

HGURES 


As  a  formal  entity,  this  template  is  essentially  a 
procedure  for  assembling  the  data  structures  that 
make  up  a  specification.  It  is  a  Lisp  program  and 
draws  on  a  set  of  predefined  functions  (e.g.  set- 
bundle-head,  no-determiner)  to  simplify  the 
statement  of  the  necessary  actions.  Every  template  is 


required  to  provide  all  of  the  elements  that  make  up  a 
properly  formed  realization  specification.  In  this 
case  a  bundle  for  a  noun  phrase  is  being  assembled, 
and  so  there  must  be  a  kernel  built  for  the  head  of  the 
bundle  and  values  given  for  all  the  accessories  that 
bundles  of  that  type  require.  Since  the  phrases 
specified  by  this  particular  template  are  compositions 
linguistically,  i.e.  they  involve  the  adjunction  of  two 
modifiers  to  the  inital  np-common-noun,  the  template 
includes  operations  ("add-specializing-description") 
that  add  the  sources  of  the  modifiers  using  the  proper 
attachment  function. 

These  same  techniques  may  be  used  to  generate 
longer  texts.  The  following  example  differs  from  the 
last  one  in  three  ways: 

(1)  The  templates  are  building  larger  structures: 
discourse  units  which  produce  multiple  sentences  and 
clause  bundles  which  produce  complex  sentences. 

(2)  Default  mappings  are  defined  between  classes 
of  objects  and  templates  rather  than  having  to  define  a 
mapping  for  each  instance  of  the  class. 

(3)  Templates  can  be  called  explicitly  from  other 
templates  with  a  dynamically  chosen  set  of 
arguments. 

The  example  is  from  one  of  the  generation  tasks 
in  the  ALBM  domain:  to  produce  a  "mission 
restatement"  paragraph  describing  the  essential  tasks 
in  some  operation.  These  tasks  are  presented  to  the 
generator  as  a  simple  list  of  TASK-OBJECTS, 
expressing  the  who,  what,  when,  where,  and  why  of 
the  task,  along  with  a  dependency  graph  representing 
the  relations  between  them.  Figure  4  shows  an 
example  of  a  task  object  and  a  portion  of  a  mission 
restatment  paragraph  produced  by  our  current 
prototype  of  the  text  planner. 


♦<unit  TOl.  ATTACK* 

parent:  ♦<unit  TASK.oajECT> 
slots : 

unit :  #<unit  10th-corp> 
action:  ♦<unit  attack> 
objective:  #<unit  NORTHEAST> 
intent:  (Kunit  SECURE. objectives>  > 

"lOth  (U.S.)  Corps  attacks  to  the  northeast  to 
secure  objectives.  10th  (U.S.)  Corps  exploits  east 
ofThuringer  Wald." 

FIGURE  4 


4  For  brevity  and  clanty  we  use  a  textbook  frame  style  rather 
than  showing  the  actual  KEE  underlying  reptresentation;  we  also 
show  only  the  slots  which  directly  impact  this  discussion. 
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Our  prototype  text  planner  takes  advantage  of  the 
uniformity  of  the  objects  in  the  underlying  program 
that  motivates  the  text  and  the  uniformity  in  the  form 
of  the  paragraphs  to  be  produced.  These  uniformities 
allow  us  to  use  predefined  templates  for  these 
paragraphs  in  much  the  same  way  as  McKeown  used 
schemas  to  produce  the  overall  organization  of 
definitions  of  data  base  attributes  (McKeown,  1985). 
Note  that  there  are  two  very  important  assumptions 
inherent  in  this  approach:  First,  the  information 
needed  is  explicitly  represented  in  data  structures  in 
the  underlying  program.  Second,  those  data 
structures  are  stable,  that  is,  in  the  lifetime  of  the 
project,  the  structures  will  not  change,  or  if  they  do, 
then  the  specific  templates  that  access  them  must 
change  as  well. 


(def ine-default-3pecif ication 

(lc:unit  'K:  :ta3)c. object) 
:  template-name  express-tasic 
; arguments  ()) 


(def ine-speoif ication-template  express-task®  () 
(let*  ((r-fn  (instantiate-raapping 
(k;unlt 

(k:get. value  self  'k; :action) ) ) ) 
(agent  (instantiate-mapping 
(k:unit 

(k:get. value  self  'k::unit)))) 

(k  (make-a-kernel  r-fn  agent)) 

(loc  (when 

(k;get. value  self  'K: iobjective) 
(make-a-further-3pecif ication 
' location-modifier 
(instantiate-mapping 
(k:unit 

(k:get. value  self 

'K: : objective) ) ) 

))) 

(intent  (when 

(k:get. value  self  'K:;intent) 
(make-a-further-specif ication 
' rationale-modifier 
(k:unit 

(k: get. value  self 

'K: :intent) ) 

)))) 

(f uncall-template  ' current -event-with-modifiers 
k  loc  intent) ) ) 
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^  Self  is  bound  to  the  instance  being  mapped  at  the  time  the 
mapping  occurs;  in  this  case,  it  is  bound  to  the  unit  tol. attack. 


The  top  level  function  for  generating  the  mission 
paragraph  builds  a  discourse  unit  bundle  with  the 
first  task-object  as  the  head  of  the  bundle  and  the  rest 
as  an  ordered  list  of  further-specifications.  Since  the 
relations  between  the  task  objects  in  this  example  is 
simply  sequential-temporal,  the  default  attachment 
function  "new  sentence"  is  used,  resulting  a  sequence 
of  separate  sentences,  one  for  each  task. 

Figure  5  shows  the  default  specifications  for  the 
class  task-object  and  the  template  it  references. 

This  template  is  a  specialist  which  picks  out  the 
information  from  the  task  object  to  be  included  in  the 
mission  paragraph.  Note  that  the  modularity  of  the 
task  objects  is  different  from  that  of  the  actual 
sentences  which  express  them.  The  action  and  unit 
combine  to  form  the  matrix  of  the  sentence  and  other 
slots  function  as  adjuncts,  such  as  the  location  and 
intent.  The  template  shown  in  Figure  6  combines 
these  elements  into  a  clause  bundle  and  sets  the 
accessories  to  unmarked  (not  a  question  or  command) 
and  simple  present  tense.  These  features  are 
stipulated  as  part  of  the  style  of  these  paragraphs 
rather  than  stemming  from  anything  in  the 
underlying  representation. 

(define-template  current-event-with-modif iers 
(event  Srest  modifiers) 

(let  ( (b  (make-a-bundle  'general-clause)) 
(set-bundle-)iead  b  event) 

(present-tense  b) 

(unmarked  b) 

(dolist  (m  modifers) 

(add-already-built-further-specification  m  b) 
b)  ) 
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In  the  examples  described  above,  our  use  of 
templates  is  a  shorthand  for  building  realization 
specifications.  As  such  it  is  appropriate  for  the  very 
simple  text  planning  that  typifies  today's  generation 
applications;  Already  formed  objects  and 
expressions  in  the  underlying  application  program 
can  be  associated  directly  with  semi-custom  templates 
with  the  English  words  introduced  as  arguments.  In 
more  complex  text  planning  where,  for  example,  the 
same  objects  are  presented  from  different 
perspectives  depending  on  the  communicative 
situation,  there  is  unlikely  to  already  be  any 
expression  with  the  right  properties,  and  it  will  be  the 
planner's  task  to  construct  one.  Here  too,  our  facility 
for  mapping  objects  to  specifications  will  be  very 
useful. 
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COMPOSING  SPECIFICATIONS 

In  this  section  we  look  ahead  to  the  development 
of  general  planners  with  the  ability  to  dynamically 
select  and  orchestrate  information  from  the 
underlying  program  to  fit  the  occasion.  One  of  a 
planner's  prime  abilities  will  be  to  appreciate  the 
functions  and  consequences  of  alternative  forms  and 
combinations  by  which  the  same  body  of  information 
can  be  communicated.  Our  specification  language 
permits  such  alternatives  to  be  simply  stated.  We  can 
see  this  in  an  illustration  taken  from  our  ongoing 
work  with  the  KRS  system  in  use  at  the  Rome  Air 
Development  Center.  KRS  ("Chris")  is  a  rule  based 
system  for  mission  planning.  Its  internal 
representation  is  based  on  instantiating  relations 
represented  as  lists  of  symbols:  for  example  the  three 
relations  shown  below  in  Figure  7  ("facts"  in  the 
lefthand  side  of  one  of  KRS's  production  rules), 
along  with  their  English  realizations  as  given  by  the 
direct  replacement  generator  presently  included  with 
KRS. 

(target  OCA1002  BE50318) 

(POWA  BE50318  BE503 18-Search-Radar) 

(IS-A  BE50318-Search-Radar  Electronics) 

The  target  of  OCA1002  is  BE503I8.  Part  of 

BE50318  is  BE503 18-Search-Radar.  BE50318- 

Search-Radar  radiates. 

nOURE? 

While  perhaps  good  enough  to  serve  its  purpose 
(i.e.  as  part  of  the  KRS  rule-editor),  this  text  is 
unnatural— no  person  would  ever  say  it.  Stylistically 
it  is  chunky  and  awkward,  but  more  importantly,  it 
actually  mis-communicates  the  relative  value  of  the 
three  facts  by  giving  them  equal  weight  in  the 
utterance. 

A  sophisticated  text  plaimer  would  want  to  convey 
not  just  propositional  information  but  also  to  indicate 
its  rhetorical  significance,  e.g.  what  is  important, 
what  is  unusual.  In  the  present  case,  the  fact  about  the 
assignment  of  the  target  was  specified  by  the  user  and 
is  thus  a  given.  The  fact  that  the  target  has  a  search 
radar  may  or  may  not  already  be  known.  The  fact 
that  this  particular  radar  is  known  to  be  active  is  the 
most  significant,  since  it  is  this  fact  that  has  an  impact 
on  the  planning  of  the  mission  (i.e.  there  now  have  to 
be  radar-suppression  aircraft  included). 

Depending  on  whether  or  not  the  existence  of  the 
search  radar  is  known,  a  much  improved  rendering 
of  the  three  facts  could  be  one  of  these  two: 


"The  target  has  an  active  search  radar" 

"The  target's  search  radar  is  active" 

Given  that  we  will  have  already  established 
mappings  to  suitable  templates  for  each  of  the  three 
facts  independently,  the  specification  of  a  single 
sentence  expressing  all  three  becomes  a  matter  of 
combining  them  into  a  single  specification,  varying 
their  positions  as  bundle  heads  or  further 
specifications  and  specifying  the  appropriate 
attachment  functions.  This  ability  to  combine  parts 
without  affecting  their  internal  structure  is  one  of  the 
most  powerful  aspects  of  our  specification  language. 

The  specification  for  "The  target  has  an  active 
search  radar"  (Figure  8)  would  be  built  by  using  the 
second  fact,  "part  of,  as  the  backbone  of  the  bundle, 
supplying  Ae  head  and  thereby  the  main  verb  has. 
The  first  fact- (target  . . .  BE503i8)-is  then  folded 
in  as  the  way  of  describing  BE50318  (interpreting  the 
fact  as  ascribing  the  functional  role  of  "target"  to  its 
second  argument,  the  "battle  element"),  and  the  third 
fact — (isa  . . .  electronics) —becomes  a  modifier  in 
the  description  of  the  search  radar. 

Alternatively,  to  specify  "The  target’s  search 
radar  is  active"  (Figure  9),  one  would  position  the 
third  fact  as  the  head  of  the  bundle  and  use  the  first 
two  as  the  characterization  of  the  search  radar.  As 
indicated  on  the  two  figures,  these  specifications  are 
assembled  from  exactly  the  same  three  partial 
specifications,  but  combined  in  different  orders  with 
different  attachment  functions. 

Note  that  the  pretty-printing  of  these 
specifications  is  a  little  simpler  than  the  earlier  ones 
so  as  to  conserve  space,  and  that  it  includes  another 
field— "underlying-object"— to  make  the  origins  of 
the  different  parts  of  the  specification  clearer. 

One  other  point  that  may  be  unexpected  is  the  fact 
that  the  Figures  include  two  instances  of  the 
specification  for  the  search  radar,  one  as  the  second 
argument  to  have  as  we  would  expect,  and  a  second 
embedded  within  the  first  as  part  of  the  "clause" 
specification  for  (isa  ...  electronics).  Of  course, 
if  this  second  instance  were  missing— say  as  the  result 
of  some  planning-level  abbreviation  in  recognition 
that  only  the  adjective  within  that  specification  was 
going  to  actually  appear  in  the  final  text— then  the 
Specifications  in  the  two  figures  would  not  just  be 
simple  rearrangements  of  the  same  parts  (a 
generalization  we  consider  valuable);  instead  we 
have  the  selection  of  the  adjective  done  as  part  of 
realization  as  one  of  the  normal  choices  for  simple 
predications,  under  control  of  the  position  where  the 
specification  is  attached,  i.e.  as  a  modifier  to  an  NP. 
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#<bundle  general-clause 
: underlying-object  (POWA  ...  search-radar) 

:head 

#<lcernel  HAVE-as-possession  - 

(  #<bundle  general-np 

: underlying-object  BE50318 
:head  #<lcernel  NP-common-noun 
("target") > 

:accessories  (inumber  singular 
: gender  neuter 
; person  third 
: determiner-policy 

always-def inite) > 

#<bundle  general-np 

: underlying-object  BE50318-3earch-radar 
:head  #<kernel  NP-common-noun 
( "radar" )> 

:accessories  (;number  singular 
: gender  neuter 
: person  third 
: determiner-policy 

always-def inite) 

:  further-specifications 
( ( : specification 

#<kernel  common-noun 
("search") > 

: attachment-function  classifier) 

( : specification 

#<bundle  general-clause 
: underlying-object  (ISA. . .electronics) 
:head 

#<kernel  predication_to-be  - 

(♦<bundle  general-np 
: underlying-object 

BE50318-search-tadar 
: head  Ikketnel  NP-oommon-noun 
("radar") > 

:aoces3orie3  (:number  singular 
: gender  neuter 
! person  third 
: determiner-policy 
always-def inite) 

:  further-specifications 
( ( :  specification 

♦<kernel  common-noun 
("search") > 

: attachment-function 

classifier) ) > 
#<kernel  ADJP-adjective 

("active") >  )  » 

: attachment-function  restrictive-modifier 
))>  )> 

; accessories 
( : unmarked 

: tense-modal  present) > 


#<bundle  general-clause 
: underlying-object  (ISA. . .electronics) 

:head 

#<kernel  predication_to-be 
(  #<bundle  general-np 

: underlying-object  BE50 3 18-search-radar 
:head 

#<kernel  NP-common-noun 
("radar") > 

:accessories  (inumber  singular 
: gender  neuter 
:person  third 
: determiner-policy 

always-def inite) 

: further-specifications 
( ( : specification 

#<kernel  common-noun 
("search")  > 

: attachment-function  classifier)) 

( : specif ication 

#<kernel  HAVE-as-possession 
(  #<bundle  general-np 

: underlying-object  BE50318 
ihead  #<kernel  NP-common-noun 
("target") > 

raccessories  (:number  singular 
tgender  neuter 
rperson  third 
: determiner-policy 
always-def inite) > 
#<bundle  general-np 
: underlying-object 

BE50 3 18-search-radar 
:head  #<kernel  NP-common-noun 
("radar") > 

:accessorie3  (inumber  singular 
: gender  neuter 
: person  third 
: determiner-policy 
always-def inite) 

:  further-specifications 
(  ( : specif ication 

♦<kernel  common-noun 
("search") > 

: attachment-function 

classifier) ) 

: attachment-function  possessive  ))> 

#<kernel  ADJP-adjective 
("active")  >  )> 

:  accessories 
( ; unmarked 

: tense-modal  present) > 


'The  target  has  an  active  search  radar." 


'The  target's  search  radar  is  active.' 


HGURES 


nGURE9 
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CONCLUSION 

The  specification  language  has  been  completely 
implemented  and  used  in-house  since  the  fall  of  1986. 
The  templates  and  the  specifics  of  how  objects  and 
expressions  in  underlying  applications  and  planners 
are  to  be  linked  to  Mumble-86  have  evolved  over  that 
time  and  may  continue  to  evolve  somewhat  as  we  get 
more  experience  with  other  applications.  Mumble- 
86  itself  is  currently  being  used  both  for  applications 
and  as  a  research  tool  at  a  variety  of  sites  including 
the  University  of  Massachusetts,  BBN  Labs,  RADC, 
and  University  of  Pennsylvania. 

As  part  of  an  excercise  in  learning  how  to  use 
Mumble-86,  two  researchers  from  RADC,  Sharon 
Walter  and  Doug  White,  recently  extended  the 
program  to  generate  in  KRS's  domain.  It  took  them 
only  two  days  to  learn  the  specification  language, 
build  input  specifications,  and  make  the  necessary 
grammatical  and  lexical  extensions  to  generate 
several  sentences  in  their  domain,  including  those 
shown  in  Figure  7.  Neither  had  used  Mumble-86 
before. 

In  conclusion  we  would  like  to  emphasize  two 
main  points.  The  first  is  the  importance  of 
modularity  in  design  and  portability  of  the  modules 
so  that  research  can  concentrate  on  new  and  hard 
problems  without  having  to  waste  effort  reinventing 
the  wheel.  Mumble-86  has  been  developed  to  be  just 
such  a  portable  module.  It  has  the  responsibility  for 
all  syntactic  decisions  without  making  presumptions 
about  the  semantic  model  of  the  application  program 
that  uses  it 


Our  second  point  is  that  a  designer  should  not 
compromise  the  integrity  of  a  well  developed  module 
to  accomodate  one  which  is  less  well  developed  when 
the  two  are  brought  together  in  the  same  system. 
This  is  the  purpose  of  the  input  specification  language 
we  have  introduced  in  this  paper.  In  developing  this 
language,  we  have  clarified  what  decisions  have  to  be 
made  outside  Mumble-86  and  which  decisions  are  its 
responsibility,  thus  circumscribing  its  sphere  of 
influence  and  making  it  more  useful  as  a  domain 
independent  linguistic  component  and  as  a  tool  for 
research  in  text  planning  and  discourse  structure. 
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